ETSITS132 642V4.2.0 



(2002-09) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

Telecommunication management; 

Configuration Management (CM); 

UTRAN network resources Integration Reference Point (IRP): 

Network Resource Model (NRM) 
(3GPP TS 32.642 version 4.2.0 Release 4) 



3ji^ 




3GPP TS 32.642 version 4.2.0 Release 4 1 ETSI TS 1 32 642 V4.2.0 (2002-09) 



Reference 



RTS/TSGS-0532642V420 
Keywords 



UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, send your comment to: 
editor(5)etsi.fr 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2002. 
All rights reserved. 

DECT'^", PLUGTESTS™ and UMTS™ are Trade IVlarks of ETSI registered for the benefit of its IVIembers. 
TIPHON^" and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



3GPP TS 32.642 version 4.2.0 Release 4 2 ETSI TS 1 32 642 V4.2.0 (2002-09) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under www.etsi.org/kev . 



ETSI 



3GPP TS 32.642 version 4.2.0 Release 4 3 ETSI TS 1 32 642 V4.2.0 (2002-09) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 4 

Introduction 4 

1 Scope 6 

2 References 6 

3 Definitions and abbreviations 7 

3.1 Definitions 7 

3.2 Abbreviations 8 

4 System overview 9 

4.1 System context 9 

4.2 Compliance rules 10 

5 Modelling approach 10 

6 IRP Information Model 10 

6.1 Introduction 10 

6.2 Managed Object Class (MOC) diagrams 11 

6.2.1 Inheritance hierarchy 11 

6.2.2 Containment/Naming and Association diagrams 11 

6.3 Managed Object Class (MOC) definitions 13 

6.3.1 MOC RncFunction 13 

6.3.2 MOC NodeBFunction 14 

6.3.3 MOCUtranCell 15 

6.3.4 MOCIubLink 16 

6.3.5 MOC UtranRelation 17 

6.3.6 MOC ExternalUtranCell 18 

6.4 Associations 18 

6.4.1 Association ConnectedTo (M) 18 

6.4.2 Association AssociatedWith (M) 18 

Annex A (informative): Supported UTRAN network configurations 19 

Annex B (informative): Change history 21 

History 22 



£75/ 



3GPP TS 32.642 version 4.2.0 Release 4 4 ETSI TS 1 32 642 V4.2.0 (2002-09) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service (QoS). The CM actions are 
initiated either as single actions on single NEs of the 3G network, or as part of a complex procedure involving actions 
on many resources/objects in one or several NEs. 

Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G network as it evolves. CM actions have the objective to control and monitor the actual configuration 
on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator or by 
functions in the Operations Systems (OSs) or NEs. 

Due to the growing number of specifications to model new services and Resource Models for Configuration 
Management (CM), as well as the expected growth in size of each of them from 3GPP Release 4 onwards, a new 
structure of the specifications is already needed in Release 4. This structure is needed for several reasons, but mainly to 
enable more independent development and release for each part, as well as a simpler document identification and 
version handling. Another benefit would be that it becomes easier for bodies outside 3GPP, such as the ITU-T, to refer 
to telecom management specifications from 3GPP. The new structure of the specifications does not lose any 
information or functionality supported by the Release 1999. The restructuring also includes defining new IRPs for the 
Network Resource Models (Generic, Core Network and UTRAN NRM). 

Finally, the Name convention for Managed Objects (in Release 1999: 32.106-8) has been moved to a separate number 
series used for specifications common between several management areas (e.g. CM, FM, PM). 

The following table shows an overview of the mapping between the old Release 1999 and new Release 4 CM 
specification structure. 
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Table: Mapping between Release "99 and the new Rel-4 specifications 



R99 
Old no. 


Old (R99) specification title 


Rel-4 
New no. 


New (Rel-4) specification title 


32.106-1 


3G Configuration Management: Concept and Requirements 


32.600 


3G Configuration Management: Concept and 
High-level Requirements 


32.106-1 


<Notification IRP requirements from 32.106-1 and 32.106-2> 


32.301 


Notification IRP: Requirements 


32.106-2 


Notification IRP: IS 


32.302 


Notification IRP: Information Service 


32.106-3 


Notification IRP: CORBA SS 


32.303 


Notification IRP: CORBA SS 


32.106-4 


Notification IRP: CMIP SS 


32.304 


Notification IRP: CMIP SS 


32.106-8 


Name convention for Managed Objects 


32.300 


Name Convention for Managed Objects 


32.106-1 


<Basic CM IRP IS requirements from 32.106-1 and 32.106-5> 


32.601 


Basic CM IRP: Requirements 


32.106-5 


Basic CM IRP IM (Intro & IS part) 


32.602 


Basic CM IRP: Information Service 


32.106-6 


Basic CM IRP CORBA SS (IS related part) 


32.603 


Basic CM IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (IS related part) 


32.604 


Basic CM IRP: CMIP SS 


32.106-8 


Name convention for Managed Objects 


32.300 


Name Convention for Managed Objects 


- 


- 


32.611 


Bulk CM IRP: Requirements 


- 


- 


32.612 


Bulk CM IRP: Information Service 


- 


- 


32.613 


Bulk CM IRP: CORBA SS 


- 


- 


32.614 


Bulk CM IRP: CMIP SS 






32.615 


Bulk CM IRP: XML file format definition 


32.106-1 


<Basic CM IRP Generic NRM requirements from 32.106-1 and 
32.106-5> 


32.621 


Generic Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (Generic NRM part) 


32.622 


Generic Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (Generic NRM related part) 


32.623 


Generic Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (Generic NRM related part) 


32.624 


Generic Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP CN NRM requirements from 32.106-1 and 32.106- 
5> 


32.631 


Core Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (CN NRM part) 


32.632 


Core Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (CN NRM related part) 


32.633 


Core Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (CN NRM related part) 


32.634 


Core Network Resources IRP: CMIP SS 


32.106-1 


<Basic CM IRP UTRAN NRM requirements from 32.106-1 and 
32.106-5> 


32.641 


UTRAN Network Resources IRP: Requirements 


32.106-5 


Basic CM IRP IM (UTRAN NRM part) 


32.642 


UTRAN Network Resources IRP: NRM 


32.106-6 


Basic CM IRP CORBA SS (UTRAN NRM related part) 


32.643 


UTRAN Network Resources IRP: CORBA SS 


32.106-7 


Basic CM IRP CMIP SS (UTRAN NRM related part) 


32.644 


UTRAN Network Resources IRP: CMIP SS 






32.651 


GERAN Network Resources IRP: Requirements 






32.652 


GERAN Network Resources IRP: NRM 






32.653 


GERAN Network Resources IRP: CORBA SS 






32.654 


GERAN Network Resources IRP: CMIP SS 
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Scope 



The present document is part of an Integration Reference Point (IRP) named "UTRAN Network Resources IRP", 
through which an "IRP Agent" (typically an Element Manager or Network Element) can communicate Configuration 
Management information to one or several "IRPManagers" (typically Network Managers) concerning UTRAN 
resources. The "UTRAN Network Resources IRP" comprises a set of specifications defining Requirements, a protocol 
neutral Network Resource Model (NRM) and corresponding Solution Set(s). 

The present document 

1 . specifies the protocol neutral UTRAN Network Resources IRP: Network Resource Model. It reuses relevant 
parts of the generic NRM in [16], either by direct reuse or sub-classing, and in addition to that defines UTRAN 
specific Managed Object Classes. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs - as described in the Introduction clause above. An important aspect of such a split is that the 
Network Resource Models (NRMs) defined in different IRPs containing NRMs are consistent, and that NRMs 
supported by an IRP Agent implementation can be accessed as one coherent model through one IRP Information 
Service. 

To summarize, the present document has the following main purpose: 

(1) to define the applied UTRAN specific Network Resource Model, based on the generic NRM in [16]. 

Finally, in order to access the information defined by this NRM, an IRP Information Service (IS) is needed, such as the 
Basic CM IRP: IS [17] or the Bulk CM IRP: IS [18]. However, which Information Service that is applicable is outside 
the scope of this document. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "3G Telecom Management principles and high level requirements". 

[2] 3GPP TS 32.102: "3G Telecom Management architecture". 

[3] 3GPP TS 23.003: "Numbering, addressing and idenfification". 

[4] 3GPP TS 25.401: "UTRAN Overall Description" 

[5] 3GPP TS 25.433: "UTRAN lub Interface NBAP Signalling" 

[6] 3GPP TS 25.423: "UTRAN lur Interface RNSAP SignalHng" 

[7] ITU-T Recommendation X.710 (1991): "Common Management Information Service Definition 

for CCITT Applications". 

[8] Void 

[9] Void 

[10] Void 
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[11] 3GPP TS 32.1 1 1-2: "Fault Management (FM); Part 2: Alarm Integration Reference Point (IRP); 

Information Service Version 1". 

[12] Void 

[13] 3GPP TS 32.300: "Configuration Management (CM); Name convention for Managed Objects". 

[14] 3GPP TS 32.600: "Configuration Management (CM); Concept and main requirements". 

[15] 3GPP TS 23.002: "Network Architecture". 

[16] 3GPP TS 32.622: "Configuration Management (CM); Generic network resources Integration 

Reference Point (IRP): Network Resource Model (NRM)". 

[17] 3GPP TS 32.602: "Configuration Management (CM); Basic CM Integration Reference Point (IRP) 

information model". 

[18] 3GPP TS 32.612: "Configuration Management (CM); Bulk CM Integration Reference Point (IRP); 

Information service". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.600 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently (in R99) however, all (non-containment) associations are modelled by means of 
reference attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class ManagedElement defined in [16]. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class (the term "attribute" is taken from TMN and corresponds to a "property" according to CIM). 
Furthermore, an MO class can have operations that represent the behaviour relevant for that class (the term "operation" 
is taken from TMN and corresponds to a "method" according to CIM). An MO class may support notifications that 
provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 

(3) a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 3.1 depicts the relationships 
between a Name space and a number of participating MOs (the shown association is of a non-containment 
type) 
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Figure 3.1 : Relationships between a Name space and a number of participating MOs 
Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.300 [13]) restricts the 
name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DN Distinguished Name (see 3GPP TS 32.300 [13]) 

EM Element Manager 

FM Fault Management 

IRP Integration Reference Point 

ITU-T International Telecommunication Union, Telecommunication Sector 

lub Interface between RNC and Node B 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MO Managed Object 

MOC Managed Object Class 

NE Network Element 

NM Network Manager 

NR Network Resource 

NRM Network Resource Model 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.300 [13]) 

RNC Radio Network Controller 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

UTRAN UMTS Terrestrial Radio Access Network 

XML extensible Mark-up Language 
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4 System overview 

4.1 System context 

Figure 4. 1 and 4.2 identify system contexts of the IRP defined by the present document in terms of its implementation 
called IRP Agent and the user of the IRP Agent, called IRPManager. For a definition of IRPManager and IRP Agent, see 

3GPPTS 32.102 [2]. 

The IRP Agent implements and supports this IRP. The IRP Agent can reside in an Element Manager (EM; for definition 
see 3GPP TS 32.101 [1]) or a Network Element (NE) (see also [2] clause 8). In the former case, the interface 
(represented by a thick dotted line) between the EM and the NEs is not the subject of this IRP. 

The IRP Agent implements and supports the Basic CM IRP. The IRP Agent can be an Element Manager (EM) or a 
mediator that interfaces one or more NEs (see Figure 4.1), or it can be a Network Element (NE) (see Figure 4.2). In the 
former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not subject of this IRP. 

An IRPManager using this IRP shall choose one of the two System Contexts defined here, for each NE. For instance, if 
an EM is responsible for managing a number of NEs, the NM shall access this IRP through the EM and not directly to 
those NEs. For another IRP though, the System Context may be different. 
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Figure 4.1 : System Context A 
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Figure 4.2: System Context B 
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4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 

The following defines the meaning of Mandatory and Optional MOC attributes and associations between MOCs, in 
Solution Sets to the IRP defined by the present document. 

Solution Sets to the Basic CM IRP: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 

• The IRP Agent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRP Agent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
SA5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRP Agent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor- specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 



5 Modelling approach 

The modelling approach adopted and used in this IRP is described in the Generic Network Resources IRP: NRM [16]. 



IRP Information Model 



6.1 Introduction 

As already introduced in the previous clause, the present clause defines the UTRAN Network Resources IRP: Network 
Resource Model. That is, this model defines UTRAN specific MOCs that shall be contained by the generic MOCs 
defined in [16]. 

The managed object classes in this NRM are protocol environment neutral and the model does not define the syntax or 
encoding of the operations and parameters. 

It should be noted that this model allows for combined managed element functionality, where more than one "function 
MOCs" (inherited from ManagedFunction) modelling more specific managed element functionality may be contained 
in the ManagedElement MOC. 

The Information Service(s) to access managed objects of this NRM is defined elsewhere. 

The corresponding Solution Set specifications provide protocol dependent definitions. They provide the actual 
realization of the operations and notifications defined in this subclause in each protocol environment. One may find that 
the class/attribute definitions in the protocol-neutral model differ from those defined in the Solution Sets (e.g. due to 
mappings to existing standard models that are applicable for a specific Solution Set). 
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6.2 Managed Object Class (MOC) diagrams 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example: If Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPP TS 32.111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 
Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 

6.2.1 Inheritance hierarchy 

Figure 6.1 shows the inheritance hierarchy for the UTRAN NRM. 



ManagedFunction 

(from 32.622) 



RncFunction 



NodeBFunction 




UtranCell 



UtranRelation 



ExternalUtranCell 



Figure 6.1 : UTRAN NRM Inheritance Hierarchy 

6.2.2 Containment/Naming and Association diagrams 

Figure 6.2 and 6.3 show the containment/naming hierarchy and the associations of the UTRAN NRM. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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<lnf ormationObjectClass: 
SubNetwork (from 32.622) 




<lnf ormationObiectClass>. 
Top (from 32.622) 



<lnf ormationObjectClass>: 
ExternalUtranCell 



;< Inform at bnObje etc lass: 
MeContext (from 32.622) 




:lnf ormationObjectClass» 
ExternaiGSMCell (from 32.652) 



externalUtranNeighbourCellRelation 
0..1 



«lnf ormationObiectClass» 
ManagedElement (from 32.622) 



<lnf ormationObjectClass>: 
RncFunction 



<lnformationObjectClass» „ ^ +radeBFunction-iubLink 
lubLink _■ — — — — - 

_+iubLink-nodeBFunction 0..1 I 



<lnf ormationObjectClass>: 
NodeBFunction 




«ln{ormationObjectClass» 
GsmRelation (from 32.652) 



NOTE 1: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 2 : The association between GsmRelation and GsmCell is optional. It may be valid if both the UtranCell and the 

GsmCell are managed by the same management node. 
NOTE 3: The UtranRelation and GeranRelation can be contained under MOCs defined in other NRMs. 

Figure 6.2: UTRAN NRM Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.300 [13] that expresses 
its containment hierarchy. As an example, the DN of a Managed Object representing a cell could have a format like: 

SubNetwork=Sweden,meContext=MEC-Gbg- 1 ,ManagedElement=RNC-Gbg- 1 , rncFunction=RF- 1 ,uti-anCell=Gbg- 1 . 
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UtranCell 



XOR 



vsDataContainer 

(from Generic Model) 

0..* 



UtranRelation 




NOTE 1 : The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 2: Each instance of the vsDataContainer shall only be contained under one MOC. The vsDataContainer can be 

contained under MOCs defined in other NRMs. 

Figure 6.3: vsDataContainer Containment/Naming and Association in UTRAN NRIV! diagram 

The vsDataContainer is only used for the Bulk CM IRP. 

6.3 Managed Object Class (MOC) definitions 
6.3.1 IVIOC RncFunction 

This Managed Object Class represents RNC functionality. For more information about the RNC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 1 : Attributes of RncFunction 



Name 


Qualifier 


Description 


rncFunctionId 


READ-ONLY, M 


An attribute whose "name+value" can be used as an RDN when naming an instance of 
this object class. This RDN uniquely identifies the object instance within the scope of its 
containing (parent) object instance. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 


mcc 


READ-WRITE, M 


Mobile Country Code, MCC. It is a part of the PLMN Id (Ref. 3 GPP TS 23.003 [3]). 


mnc 


READ-WRITE, M 


Mobile Network Code, MNC. It is a part of the PLMN Id (Ref. 3 GPP TS 23.003 [3]). 


rncid 


READ-WRITE, M 


Unique RNC ID (Ref. 3 GPP TS 23.003 [3]) 



Table 2: Notifications of RncFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 
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6.3.2 MOC NodeBFunction 

This Managed Object Class represents NodeB functionality. For more information about the NodeB, see 

3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 3: Attributes of NodeBFunction 



Name 


Qualifier 


Description 


nodeBFunctionId 


READ-ONLY, M 


An attribute whose "name-i-value" can be used as an RDM when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from IVIanagedFunction. 


nodeBFunction-lubLink 


READ-ONLY, M 


The value of this attribute shall be the DM of the related lubLink instance. 
This is a reference attribute modelling the role (of the association 
ConnectedTo) that this NodeBFunction is connected to 0-1 lubLink. 



Table 4: Notifications of NodeBFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


M, See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 
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6.3.3 



MOC UtranCell 



This Managed Object Class represents a radio cell controlled by the RNC. For more information about radio cells, see 

3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 5: Attributes of UtranCell 



Name 


Qualifier 


Description 


utranCellld 


READ-ONLY, M 


An attribute whose "name-i-value" can be used as an RDN wlien 
naming an instance of this object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object 
instance. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from IVIanagedFunction. 


eld 


READ-WRITE,M 


Cid is the identifier of a cell in one RNC (Ref. 3 GPP TS 25.401 [4]). 


localCellld 


READ-WRITE,M 


Local Cell id is used to uniquely identify the set of resources defined 
in a Node B to support a cell (as defined by a Cid Ref. 3 
GPP TS 25.401 [4]). It must be unique in Node B at a minimum, but 
may be unique in UTRAN. It can be used to tie the cell in the RNC to 
a specific set of resources in the Node B. 


uarfcnUI 


READ-WRITE, M 


The UL UTRA absolute Radio Frequency Channel number, 
UARFCN (Ref. 3 GPP TS 25.433 [5]). 


uarfcnDI 


READ-WRITE, M 


The DL UTRA absolute Radio Frequency Channel number, 
UARFCN (Ref. 3 GPP TS 25.433 [5]). 


primaryScramblingCode 


READ-WRITE, M 


The primary DL scrambling code used by the cell (Ref. 3 
GPP TS 25.433 [5]). 


primaryCpichPower 


READ-WRITE, M 


The power of the primary CPICH channel in the cell (Ref. 3 
GPP TS 25.433 [5]). 


maximumTransmissionPower 


READ-WRITE, M 


The maximum transmission power of a cell, DL Power (Ref. 3 
GPP TS 25.433 [5]). 


primary SchPower 


READ-WRITE, M 


The power of the primary synchronisation channel in the cell, DL 
Power (Ref. 3 GPP TS 25.433 [5]). 


secondarySchPower 


READ-WRITE, M 


The power of the secondary synchronisation channel in the cell, DL 
Power (Ref. 3 GPP TS 25.433 [5]). 


bchPower 


READ-WRITE, M 


The power of the broadcast channel in the cell (Ref. 3 
GPP TS 25.433 [5]). 


lac 


READ-WRITE, M 


Location Area Code, LAC (Ref. 3 GPP TS 23.003 [3]) 


rac 


READ-WRITE, M 


Routing Area Code, RAC (Ref. 3 GPP TS 23.003 [3]) 


sac 


READ-WRITE, M 


Service Area Code, SAC (Ref. 3 GPP TS 23.003 [3]). 


ura 


READ-WRITE, M 


UTRAN Registration Area, URA (Ref. 3 GPP TS 25.423 [6]). 


utranCell-lubLInk 


READ-ONLY, M 


The value of this attribute shall be the DN of the related lubLinl< 
instance. This is a reference attribute modelling the role (of the 
association AssociatedWith) that this UtranCell is associated with 0- 
1 lubLinl<. 



Table 6: Notifications of UtranCell 



Name Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 
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6.3.4 



MOC lubLink 



The "lub link" managed object is the logical link to a NodeB as seen from the RNC. For more information about the 
RNC, see 3GPP TS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 7: Attributes of lubLink 



Name 


Qualifier 


Description 


iubLinkId 


READ-ONLY, M 


An attribute whose "name-i-value" can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


iubLink-UtranCell 


READ-WRITE, M 


The value of this attribute shall be a list of the DN{s) of the related 
UtranCell instance{s). This is a reference attribute modelling the role (of 
the association AssociatedWith) that this lubLink is associated with 0-N 
UtranCells. 


iubLink-NodeBFunction 


READ-ONLY, M 


The value of this attribute shall be the DN of the related NodeBFunction 
instance. This is a reference attribute modelling the role (of the 
association ConnectedTo) that this lubLink is connected to 0-1 
NodeBFunction. 



Table 8: Notifications of lubLink 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP {3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP {3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP {3GPP TS 32.1 1 1-2 [1 Ij) 




notifyObjectCreation 







notifyObjectDeletion 
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6.3.5 MOC UtranRelation 

The "UtranRelation" managed object contains radio network related parameters for the relation to the "UtranCell" or 
"ExternalUtranCell" managed object. 

NOTE: In handover relation terms, the cell containing the UTRAN Relation object is the source cell for the 
handover. The cell referred to in the UTRAN relation object is the target cell for the handover. This 
defines a one-way handover relation where the direction is from source cell to target cell. 

Table 9: Attributes of UtranRelation 



Name 


Qualifier 


Description 


utranRelationId 


READ-ONLY, M 


An attribute whose "name+value" can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


relationlype 


READ-WRITE,M 


Type of relation: e.g. Intersystem relation, intrafrequency intrasystem relation, 
interfrequency intrasystem relation. 


adjacentCell 


READ-WRITE,M 


Pointer to UTRAN cell or external UTRAN cell. Distinguished name of the 
corresponding object. 


uarfcnUI 


READ-ONLY, 


The UL UTRA absolute Radio Frequency Channel number for another 
UTRAN cell or the external UTRAN cell, that is broadcast in System 
Information in the Cell, UARFCN (Ref. 3 GPP TS 25.433 [5]). 
See Note for the optional condition. 


uarfcnDI 


READ-ONLY, 


The DL UTRA absolute Radio Frequency Channel number for another 
UTRAN cell or the external UTRAN cell, that is broadcast in System 
Information in the Cell, UARFCN (Ref. 3 GPP TS 25.433 [5]). 
See Note for the optional condition. 


primaryScramblingCode 


READ-ONLY, 


The primary DL scrambling code for another UTRAN cell or the external 
UTRAN cell, that is broadcast in System Information in the Cell (Ref. 3 
GPP TS 25.433 [5]). 
See Note for the optional condition. 


primaryCpichPower 


READ-ONLY, 


The power of the primary CPICH channel for another UTRAN cell or the 
external UTRAN cell, that is broadcast in System Information in the Cell (Ref. 
3 GPP TS 25.433 [5]). 
See Note for the optional condition. 


lac 


READ-ONLY, 


Location Area Code, LAC (Ref. 3 GPP TS 23.003 [3]), for another UTRAN 

cell or the external UTRAN cell, that is broadcast in System Information in the 

Cell. 

See Note for the optional condition. 


NOTE: This attribute shall be included if the EM does not guarantee consistency between the cell definition and what 
is broadcast on system information. 



Table 10: Notifications of UtranRelation 



Name 


Qualifier 


Notes 


notifyAttributeValueChange 







notifyObjectCreation 







notifyObjectDeletion 








ETSI 



3GPP TS 32.642 version 4.2.0 Release 4 



18 



ETSI TS 132 642 V4.2.0 (2002-09) 



6.3.6 MOC ExtemalUtranCell 

This Managed Object Class represents a radio cell controlled by another IRP Agent. This MOC has necesssary attributes 
for inter-system handover. It contains a subset of the attributes of related MOCs controlled by another IRP Agent. The 
way to -mMaintain consistency between the attribute values of these two MOCs is outside the scope of this document. 

Table 11 : Attributes of ExtemalUtranCell 



Name 


Qualifier 


Description 


externalUtranCellld 


READ-ONLY, M 


An attribute whose "name+value" can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-WRITE, M 


A user-friendly (and user assigned) name of the associated object. 


eld 


READ-WRITE, M 


Cid is the identifier of a cell in one RNC (Ref. 3 GPP TS 25.401 [4]). 


mcc 


READ-WRITE, M 


Mobile Country Code, MCC (part of the PLMN Id, Ref. 3 GPP TS 23.003 
[3]). 


mnc 


READ-WRITE, M 


Mobile Networl< Code, MNC (part of the PLMN Id, Ref. 3 GPP TS 23.003 
[3]). 


rncid 


READ-WRITE, M 


Unique RNC ID for the drift RNC (Ref. 3 GPP TS 23.003 [3]). 


uarfcnUI 


READ-WRITE, M 


The UL UTRA absolute Radio Frequency Channel number, UARFCN 
(Ref. 3 GPP TS 25.433 [5]). 


uarfcnDI 


READ-WRITE, M 


The DL UTRA absolute Radio Frequency Channel number, UARFCN 
(Ref. 3 GPP TS 25.433 [5]). 


primaryScramblingCode 


READ-WRITE, M 


The primary DL scrambling code used by the cell (Ref. 3 GPP TS 25.433 
[51). 


primaryCpichPower 


READ-WRITE, M 


The power of the primary CPICH channel in the cell (Ref. 3 
GPP TS 25.433 [5]). 


lac 


READ-WRITE, M 


Location Area Code, LAC (Ref. 3 GPP TS 23.003 [3]). 


rac 


READ-WRITE, M 


Routing Area Code, RAC (Ref. 3 GPP TS 23.003 [3]). 



Table 12: Notifications of External UtranCel I 



Name 


Qualifier 


Notes 


notifyAttributeValueChange 







notifyObjectCreation 







notifyObjectDeletion 








6.4 



Associations 



6.4.1 Association ConnectedTo (IVI) 



This bi-directional association models the relationship between the lubLink and NodeB (through the NodeBFunction). 
It has two roles, named lubLink-NodeBFunction and NodeBFunction- lubLink. These two roles model each MOCs 
association with the other MOC. Each role is in the MOC definition mapped to a reference attribute with the same 
name. 



6.4.2 Association AssociatedWitin (M) 



This bi-directional association models the relationship between the lubLink and UtranCell. It has two roles, named 
lubLink-UtranCell and UtranCell-IubLink. These two roles model each MOCs association with the other MOC. Each 
role is in the MOC definition mapped to a reference attribute with the same name. 
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Annex A (informative): 

Supported UTRAN network configurations 

Figure A.l depicts four typical network configurations, which are supported by the UTRAN NRM over the Itf-N. 
However, this does not preclude support for other configurations. 



NM 



Itf-N 







RNC 



NodeB 



Single 
RNC or 
NodeB 



Config. 1 



Config. 2 



Config. 3 



Config. 4 



Figure A.l : Typical network configurations supported by the UTRAN NRM 

Table A. 1 shows the possible number of instances for each network configuration (counted from left to right in figure 
A.l.): 
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Table A.1 : Number of instances for each example configuration in figure A.1 



MOC 


Config. 1 


Config. 2 


Config. 3 


Config. 4 


SubNetwork 


1 


1 


1 


0..1 


ManagementNode 


1 


1 








ManagedElement 


1..N 


1..N 


1..N 


1 


MeContext 


0..M 


0..M 


0..M 


0..1 


RncFunction 


0..P 


0..P 


0..1 


0..1 


NodeBFunction 


0..Q 


0..Q 


0..(N-1) 


0..1 


lubLink 


0..Q 


0..Q 


0..(N-1) 





UtranCell 


0..R 


0..R 


0..R 


0..R 


IRPAgent 


1 


1 


1 


1 


NotificationIRP 


1 


1 


1 


1 


AlarmlRP 


0..1 


0..1 


0..1 


0..1 


BasicCmIRP 


0..1 


0..1 


0..1 


0..1 
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Annex B (informative): 
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